AWS CloudShellで「rm -rf /*」を実行してみた
よい子(大人を含む)はマネしないでね。CloudShellを再起動すればホームディレクトリ以外の領域は元に戻るのでちょっと安心。
CloudShellで実行するとまた違った面白い動作するらしい
こんにちは、OS破壊おじさんの のんピ(@non____97)です。
皆さんはOSを破壊したことはありますか? 以下記事の通り、私はあります。
そんな私にTwitterでとある方から「CloudShellで『rm -rf /*』をやると、また違った面白い動作をする」と情報をいただきました。
CloudShellはシェルプロンプトの環境でありOSではないですが、これは試さずにはいられません。
いきなりまとめ
rm -rf /*を実行すると、やっぱり/binなどディレクトリが削除され、ビルトインコマンド以外のコマンドは実行できなくなる- CloudShellを再起動すれば環境が再作成され、再度CloudShell上でコマンドを実行することは可能
- しかし、ホームディレクトリ
$HOMEは再起動しても元に戻らないので要注意
早速試してみた
普段使っているリージョンで試すと何かあった時に業務に影響が出るので、フランクフルトリージョン(eu-central-1)のCloudShellで検証してみます。
マネージメントコンソールからCloudShellのセッションを開始します。セッションを開始するとCreating the environment...となっていますが、すぐにお別れすることになります。儚いものですね。
また、複数のタブでCloudShellを開いていれば壊れゆく様を確認できるかと思ったので、別ウィンドウでもフランクフルトリージョンでCloudShellを起動しておきます。
それでは、お別れする前にCloudShellの実行環境のOSのバージョンやディレクトリ構成などを確認しておきます。
# rootユーザーへの昇格 $ sudo -i # 現在のユーザーの確認 $ whoami root # ディストリビューションの確認 $ cat /etc/system-release Amazon Linux release 2 (Karoo) $ cat /etc/os-release NAME="Amazon Linux" VERSION="2" ID="amzn" ID_LIKE="centos rhel fedora" VERSION_ID="2" PRETTY_NAME="Amazon Linux 2" ANSI_COLOR="0;33" CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2" HOME_URL="https://amazonlinux.com/" # /root ディレクトリ配下の確認 $ ls -la / total 7088 drwxr-xr-x 1 root root 4096 Dec 17 04:30 . drwxr-xr-x 1 root root 4096 Dec 17 04:30 .. drwxr-xr-x 3 root root 4096 Dec 17 04:30 aws lrwxrwxrwx 1 root root 7 Oct 1 01:14 bin -> usr/bin dr-xr-xr-x 2 root root 4096 Apr 9 2019 boot drwxr-xr-x 5 root root 340 Dec 17 04:30 dev drwxr-xr-x 1 root root 4096 Dec 17 04:30 etc drwxr-xr-x 4 root root 4096 Dec 17 04:30 home lrwxrwxrwx 1 root root 7 Oct 1 01:14 lib -> usr/lib lrwxrwxrwx 1 root root 9 Oct 1 01:14 lib64 -> usr/lib64 -rw-r--r-- 1 root root 7178320 Oct 5 10:58 libicu-50.2-4.amzn2.x86_64.rpm drwxr-xr-x 2 root root 4096 Oct 1 01:14 local drwxr-xr-x 2 root root 4096 Apr 9 2019 media drwxr-xr-x 2 root root 4096 Apr 9 2019 mnt drwxr-xr-x 1 root root 4096 Oct 5 11:01 opt dr-xr-xr-x 131 root root 0 Dec 17 04:30 proc dr-xr-x--- 1 root root 4096 Oct 5 11:01 root drwxr-xr-x 1 root root 4096 Dec 17 04:30 run lrwxrwxrwx 1 root root 8 Oct 1 01:14 sbin -> usr/sbin drwxr-xr-x 2 root root 4096 Apr 9 2019 srv dr-xr-xr-x 13 root root 0 Dec 17 04:31 sys drwxrwxrwt 1 root root 4096 Dec 17 04:30 tmp drwxr-xr-x 1 root root 4096 Oct 1 01:14 usr drwxr-xr-x 1 root root 4096 Oct 1 01:14 var # /var/log ディレクトリ配下の確認 $ ls -l /var/log/ total 296 -rw------- 1 root utmp 0 Oct 5 11:00 btmp -rw-r--r-- 1 root root 292292 Dec 17 04:47 lastlog -rw------- 1 root root 0 Oct 5 11:00 tallylog -rw-rw-r-- 1 root utmp 0 Oct 5 11:00 wtmp -rw------- 1 root root 7325 Dec 17 04:30 yum.log # マウントしているディスクの空き領域の確認 $ df -h Filesystem Size Used Avail Use% Mounted on overlay 30G 9.3G 19G 34% / tmpfs 64M 0 64M 0% /dev shm 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/xvdcz 30G 9.3G 19G 34% /aws/mde /dev/loop0 976M 2.6M 907M 1% /home tmpfs 3.9G 0 3.9G 0% /proc/acpi tmpfs 3.9G 0 3.9G 0% /sys/firmware tmpfs 3.9G 0 3.9G 0% /proc/scsi # マウントしているディスクの情報確認 $ mount overlay on / type overlay (rw,relatime,lowerdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/211/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/184/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/183/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/182/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/181/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/180/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/179/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/131/fs,upperdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/222/fs,workdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/222/work) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev type tmpfs (rw,nosuid,size=65536k,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666) shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime) mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime) sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime) tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (ro,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/devices type cgroup (ro,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (ro,nosuid,nodev,noexec,relatime,net_cls,net_prio) cgroup on /sys/fs/cgroup/cpuset type cgroup (ro,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/blkio type cgroup (ro,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/hugetlb type cgroup (ro,nosuid,nodev,noexec,relatime,hugetlb) cgroup on /sys/fs/cgroup/freezer type cgroup (ro,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/pids type cgroup (ro,nosuid,nodev,noexec,relatime,pids) cgroup on /sys/fs/cgroup/perf_event type cgroup (ro,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/memory type cgroup (ro,nosuid,nodev,noexec,relatime,memory,release_agent=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/220/fs/tmp/snappy_escape/fd9e51ef-80e1-4e7e-af81-b54cc4c4b3fc/cmd) /dev/xvdcz on /aws/mde type ext4 (rw,relatime,data=ordered) /mnt/task/volumes/0d3343351dd84ef49348e221b3266566/volumes/mde-private-volume/home.data on /home type ext4 (rw,relatime,data=ordered) /dev/xvdcz on /etc/hosts type ext4 (rw,relatime,data=ordered) /dev/xvdcz on /etc/resolv.conf type ext4 (rw,relatime,data=ordered) /dev/xvdcz on /etc/hostname type ext4 (rw,relatime,data=ordered) proc on /proc/bus type proc (ro,nosuid,nodev,noexec,relatime) proc on /proc/fs type proc (ro,nosuid,nodev,noexec,relatime) proc on /proc/irq type proc (ro,nosuid,nodev,noexec,relatime) proc on /proc/sys type proc (ro,nosuid,nodev,noexec,relatime) proc on /proc/sysrq-trigger type proc (ro,nosuid,nodev,noexec,relatime) tmpfs on /proc/acpi type tmpfs (ro,relatime) tmpfs on /proc/kcore type tmpfs (rw,nosuid,size=65536k,mode=755) tmpfs on /proc/keys type tmpfs (rw,nosuid,size=65536k,mode=755) tmpfs on /proc/latency_stats type tmpfs (rw,nosuid,size=65536k,mode=755) tmpfs on /proc/timer_list type tmpfs (rw,nosuid,size=65536k,mode=755) tmpfs on /proc/sched_debug type tmpfs (rw,nosuid,size=65536k,mode=755) tmpfs on /sys/firmware type tmpfs (ro,relatime) tmpfs on /proc/scsi type tmpfs (ro,relatime)
/var/log/messagesがあれば、tail -fで眺めてみたかったのですが、どうやら無いようですね。
なんとなくrm -rf /も実行してみました。こちらはやはり–no-preserve-rootオプションを付けなければ、削除処理が実行されない安全仕様になっています。
$ rm -rf / rm: it is dangerous to operate recursively on ‘/’ rm: use --no-preserve-root to override this failsafe
もう思い起こすことはないので、rm -rf /*を実行してあげます。
# /root ディレクトリに移動 $ cd / # 現在のディレクトリの確認 $ pwd / $ rm -rf /* . . . rm: cannot remove ‘/sys/module/jbd2/sections/.exit.text’: Read-only file system rm: cannot remove ‘/sys/module/jbd2/sections/.bss’: Read-only file system rm: cannot remove ‘/sys/module/jbd2/sections/_ftrace_events’: Read-only file system rm: cannot remove ‘/sys/module/jbd2/sections/.orc_unwind_ip’: Read-only file system rm: cannot remove ‘/sys/module/jbd2/sections/.gnu.linkonce.this_module’: Read-only file system rm: cannot remove ‘/sys/module/jbd2/sections/.symtab’: Read-only file system rm: cannot remove ‘/sys/module/jbd2/sections/.rodata’: Read-only file system rm: cannot remove ‘/sys/module/jbd2/sections/.init.text’: Read-only file system rm: cannot remove ‘/sys/module/jbd2/sections/.note.gnu.build-id’: Read-only file system rm: cannot remove ‘/sys/module/jbd2/sections/.text’: Read-only file system rm: cannot remove ‘/sys/module/jbd2/sections/.data’: Read-only file system rm: cannot remove ‘/sys/module/jbd2/sections/.smp_locks’: Read-only file system rm: cannot remove ‘/sys/module/jbd2/sections/__bug_table’: Read-only file system rm: cannot remove ‘/sys/module/jbd2/sections/.rodata.str1.1’: Read-only file system rm: cannot remove ‘/sys/module/jbd2/sections/.parainstructions’: Read-only file system rm: cannot remove ‘/sys/module/jbd2/sections/.text.unlikely’: Read-only file system rm: cannot remove ‘/sys/module/jbd2/sections/__ksymtab_strings’: Read-only file system rm: cannot remove ‘/sys/module/jbd2/sections/.rodata.str1.8’: Read-only file system rm: cannot remove ‘/sys/module/jbd2/sections/.ref.data’: Read-only file system -bash-4.2#
1分程度でコマンドの実行は完了しました。Amazon Linux 2で実行した時は20分ほどかかったので、あまり手応えがありません。
しかし、流石はrm -rf /*です。lsやwhichを叩いてもcommand not foundと片付けられてしまいました。なお、cdはビルトインコマンドであるため、rm -rf /*の影響を受けず、実行できています。ちなみに、もう片方のセッションでも試してみましたが、同様のエラーが出力されました。
# ls -l -bash: ls: command not found # cd -bash: cd: /root: No such file or directory # which -bash: /usr/bin/which: No such file or directory
CloudShellにマウントしてあるディスクをEC2インスタンスにアタッチするなどは現時点ではできないので、具体的にどこまで削除されたかをこれ以上は確認できませんでした。
取り敢えず満足したので、できれば元に戻してあげたいと思います。
試しに、セッションを一旦閉じてから再度開き直しました。すると、以下のようにとても興奮するメッセージが出力されました。
Preparing your terminal...
/root/exec-client.sh: line 2: /aws/mde/exec-vars.sh: No such file or directory
flag needs an argument: -unix
Usage of /usr/bin/controller:
-accountId string
environment owner account ID
-branch string
the branch of the repository to clone to. @optional
-cloneDir string
the directory where cloning should be performed
-controlPlaneApiGwEndpointDns string
Endpoint DNS for control plane API
-controlPlaneApiGwId string
control plane API Gateway ID
-credPort int
the port on which to run the credential server (default 1338)
-credentialsS3ObjectArn string
the S3 object ARN that contains credentials
-credentialsUpdaterEnabled
enable credentials updater (default true)
-enableControlPlaneApiFeature
enable getting credentials from control plane API
-enableHightideLoggingFeature
enable logs publishing to hightide s3 buckets
-environmentId string
environment ID
-gitCredSrvPort int
the port on which to run the git cTry these commands to get started:
aws help or aws <command> help or aws <command> --cli-auto-prompt
redential server (default 1340)
-hightideLogDir string
provide the log directory of hightide worker (default "/store/projects/.c9/worker/logs")
-mode string
the functionality to use; one of "credentials", "ssm-agent", "client", "server", "hightide-logging-daemon" (default "credentials")
-sourceURI string
the repository URI to clone
-taskArn string
the ECS task arn
-taskIdS3ObjectArn string
the S3 object ARN that contains the task ID
-unix string
the path where the exec unix socket is located (default "/aws/mde/mde.sock")
Lost your connection to the environment.
Press any key to reconnect and continue using AWS CloudShell
Connection is lost. Please refresh the browser to re-establish the connection.
どうやら、セッションを繋ぎ直しても、環境を用意するためのコマンドが実行できないようですね。
Press any key to reconnect and continue using AWS CloudShellと出力されたので、何かキーを押しても同じメッセージが繰り返し表示されるだけでした。
巷では「困った時には再起動」と金言があるので、次にCloudShellの再起動をしてみます。
Actions - Restart AWS CloudShellをクリックします。
「再起動すると現在のリージョンでアクティブなセッションが全て停止するぞ」と警告されます。もう片方のセッションも何もできない状況なので、Restartをクリックします。
すると、以下のようにStopping the environment...となりました。
CloudShellを再起動した影響で、警告された通り、もう片方のセッションは停止されていました。
そのまましばらく待つと、Waiting for the environment to run...となり、最終的に正常にCloudShellが起動しました。
ls -laやdf -hを実行した結果、どうやら元気そうですね。めでたしめでたし。
$ ls -la / total 7088 drwxr-xr-x 1 root root 4096 Dec 17 05:09 . drwxr-xr-x 1 root root 4096 Dec 17 05:09 .. drwxr-xr-x 3 root root 4096 Dec 17 05:09 aws lrwxrwxrwx 1 root root 7 Oct 1 01:14 bin -> usr/bin dr-xr-xr-x 2 root root 4096 Apr 9 2019 boot drwxr-xr-x 5 root root 340 Dec 17 05:09 dev drwxr-xr-x 1 root root 4096 Dec 17 05:10 etc drwxr-xr-x 3 root root 4096 Dec 17 05:09 home lrwxrwxrwx 1 root root 7 Oct 1 01:14 lib -> usr/lib lrwxrwxrwx 1 root root 9 Oct 1 01:14 lib64 -> usr/lib64 -rw-r--r-- 1 root root 7178320 Oct 5 10:58 libicu-50.2-4.amzn2.x86_64.rpm drwxr-xr-x 2 root root 4096 Oct 1 01:14 local drwxr-xr-x 2 root root 4096 Apr 9 2019 media drwxr-xr-x 2 root root 4096 Apr 9 2019 mnt drwxr-xr-x 1 root root 4096 Oct 5 11:01 opt dr-xr-xr-x 113 root root 0 Dec 17 05:09 proc dr-xr-x--- 1 root root 4096 Oct 5 11:01 root drwxr-xr-x 1 root root 4096 Dec 17 05:10 run lrwxrwxrwx 1 root root 8 Oct 1 01:14 sbin -> usr/sbin drwxr-xr-x 2 root root 4096 Apr 9 2019 srv dr-xr-xr-x 13 root root 0 Dec 17 05:09 sys drwxrwxrwt 1 root root 4096 Dec 17 05:10 tmp drwxr-xr-x 1 root root 4096 Oct 1 01:14 usr drwxr-xr-x 1 root root 4096 Oct 1 01:14 var $ df -h Filesystem Size Used Avail Use% Mounted on overlay 30G 9.2G 19G 33% / tmpfs 64M 0 64M 0% /dev shm 3.8G 0 3.8G 0% /dev/shm tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup /dev/nvme1n1 30G 9.2G 19G 33% /aws/mde /dev/loop0 976M 174M 736M 20% /home tmpfs 3.8G 0 3.8G 0% /proc/acpi tmpfs 3.8G 0 3.8G 0% /sys/firmware
なお、再起動前後でターミナル上に表示されているIPアドレスが10-0-110-112から10-0-178-16に変化しています。起動するタイミングでVDIのように、CloudShellの実行環境となる専用のVMごと作り直す動作をしていそうですね。
おまけ1. /binと/usr以外のディレクトリを削除してみた
/binが削除されてしまうと確認用のコマンドも打てないので、番外編として/binと/usr以外のディレクトリを削除してみます。(/usr/binではなく、/usrなのはご愛嬌)
早速以下コマンドを実行してみます。
# rootユーザーへの昇格 $ sudo -i # 現在のユーザーの確認 $ whoami root # /root ディレクトリに移動 $ cd / # 現在のディレクトリの確認 $ pwd / # /bin と /usr が含まれていないことを確認 $ ls | grep -v -E "usr|bin" aws boot dev etc home lib lib64 libicu-50.2-4.amzn2.x86_64.rpm local media mnt opt proc root run srv sys tmp var # /bin と /usr 以外のディレクトリを削除 $ ls | grep -v -E "usr|bin" | xargs rm -rf . . . rm: cannot remove ‘sys/module/jbd2/sections/__jump_table’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/.data..read_mostly’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/.strtab’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/__tracepoints_ptrs’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/__mcount_loc’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/.exit.text’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/.bss’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/_ftrace_events’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/.orc_unwind_ip’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/.gnu.linkonce.this_module’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/.symtab’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/.rodata’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/.init.text’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/.note.gnu.build-id’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/.text’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/.data’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/.smp_locks’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/__bug_table’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/.rodata.str1.1’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/.parainstructions’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/.text.unlikely’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/__ksymtab_strings’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/.rodata.str1.8’: Read-only file system rm: cannot remove ‘sys/module/jbd2/sections/.ref.data’: Read-only file system
ls | grep -v -E "usr|bin" | xargs rm -rfは30秒ほどで完了しました。
それでは、lsやdirなどコマンドを実行できるか確認してみます。
$ ls -l -bash: /bin/ls: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory $ dir -bash: /bin/dir: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory
残念ながらいずれのコマンドもシステムライブラリである/lib64/ld-linux-x86-64.so.2がないため、実行できませんでした。残念。
試しにセッションを一度閉じて再度接続してみましたが、こちらはrm -rf /*と同じメッセージが出力されました。
Preparing your terminal...
/root/exec-client.sh: line 2: /aws/mde/exec-vars.sh: No such file or directory
flag needs an argument: -unix
Usage of /usr/bin/controller:
-accountId string
environment owner account ID
-branch string
the branch of the repository to clone to. @optional
-cloneDir string
the directory where cloning should be performed
-controlPlaneApiGwEndpointDns string
Endpoint DNS for control plane API
-controlPlaneApiGwId string
control plane API Gateway ID
-credPort int
the port on which to run the credential server (default 1338)
-credentialsS3ObjectArn string
the S3 object ARN that contains credentials
-credentialsUpdaterEnabled
enable credentials updater (default true)
-enableControlPlaneApiFeature
enable getting credentials from control plane API
-enableHightideLoggingFeature
enable logs publishing to hightide s3 buckets
-environmentId string
environment ID
-gitCredSrvPort int
the port on which to run the git cTry these commands to get started:
aws help or aws <command> help or aws <command> --cli-auto-prompt
redential server (default 1340)
-hightideLogDir string
provide the log directory of hightide worker (default "/store/projects/.c9/worker/logs")
-mode string
the functionality to use; one of "credentials", "ssm-agent", "client", "server", "hightide-logging-daemon" (default "credentials")
-sourceURI string
the repository URI to clone
-taskArn string
the ECS task arn
-taskIdS3ObjectArn string
the S3 object ARN that contains the task ID
-unix string
the path where the exec unix socket is located (default "/aws/mde/mde.sock")
Lost your connection to the environment.
Press any key to reconnect and continue using AWS CloudShell
Connection is lost. Please refresh the browser to re-establish the connection.
しょうがないので、伝家の宝刀CloudShell再起動を試してみます。再起動後は以下のように正常にコマンドを実行できました。流石です。
$ ls -l / total 7080 drwxr-xr-x 3 root root 4096 Dec 18 07:57 aws lrwxrwxrwx 1 root root 7 Oct 1 01:14 bin -> usr/bin dr-xr-xr-x 2 root root 4096 Apr 9 2019 boot drwxr-xr-x 5 root root 340 Dec 18 07:57 dev drwxr-xr-x 1 root root 4096 Dec 18 07:57 etc drwxr-xr-x 3 root root 4096 Dec 18 07:57 home lrwxrwxrwx 1 root root 7 Oct 1 01:14 lib -> usr/lib lrwxrwxrwx 1 root root 9 Oct 1 01:14 lib64 -> usr/lib64 -rw-r--r-- 1 root root 7178320 Oct 5 10:58 libicu-50.2-4.amzn2.x86_64.rpm drwxr-xr-x 2 root root 4096 Oct 1 01:14 local drwxr-xr-x 2 root root 4096 Apr 9 2019 media drwxr-xr-x 2 root root 4096 Apr 9 2019 mnt drwxr-xr-x 1 root root 4096 Oct 5 11:01 opt dr-xr-xr-x 110 root root 0 Dec 18 07:57 proc dr-xr-x--- 1 root root 4096 Oct 5 11:01 root drwxr-xr-x 1 root root 4096 Dec 18 07:57 run lrwxrwxrwx 1 root root 8 Oct 1 01:14 sbin -> usr/sbin drwxr-xr-x 2 root root 4096 Apr 9 2019 srv dr-xr-xr-x 13 root root 0 Dec 18 07:57 sys drwxrwxrwt 1 root root 4096 Dec 18 07:57 tmp drwxr-xr-x 1 root root 4096 Oct 1 01:14 usr drwxr-xr-x 1 root root 4096 Oct 1 01:14 var $ ls -l /lib64/ld-linux-x86-64.so.2 lrwxrwxrwx 1 root root 10 Oct 1 01:14 /lib64/ld-linux-x86-64.so.2 -> ld-2.26.so
おまけ2. chmod -R 000 / を実行してみた
なんだか消化不良なので、もはやrm -rf /*の派生系でも何でもないですが、chmod -R 000 /を実行して/root配下の権限を全て奪ってみます。
早速以下コマンドを実行してみます。
# rootユーザーへの昇格 $ sudo -i # 現在のユーザーの確認 $ whoami root # /root ディレクトリに移動 $ cd / # 現在のディレクトリの確認 $ pwd / # /root 配下の全てのディレクトリとファイルの読み取り、書き込み、実行権限を無効化 $ chmod -R 000 / . . . chmod: changing permissions of ‘/sys/module/jbd2/sections/_ftrace_events’: Read-only file system chmod: changing permissions of ‘/sys/module/jbd2/sections/.orc_unwind_ip’: Read-only file system chmod: changing permissions of ‘/sys/module/jbd2/sections/.gnu.linkonce.this_module’: Read-only file system chmod: changing permissions of ‘/sys/module/jbd2/sections/.symtab’: Read-only file system chmod: changing permissions of ‘/sys/module/jbd2/sections/.rodata’: Read-only file system chmod: changing permissions of ‘/sys/module/jbd2/sections/.init.text’: Read-only file system chmod: changing permissions of ‘/sys/module/jbd2/sections/.note.gnu.build-id’: Read-only file system chmod: changing permissions of ‘/sys/module/jbd2/sections/.text’: Read-only file system chmod: changing permissions of ‘/sys/module/jbd2/sections/.data’: Read-only file system chmod: changing permissions of ‘/sys/module/jbd2/sections/.smp_locks’: Read-only file system chmod: changing permissions of ‘/sys/module/jbd2/sections/__bug_table’: Read-only file system chmod: changing permissions of ‘/sys/module/jbd2/sections/.rodata.str1.1’: Read-only file system chmod: changing permissions of ‘/sys/module/jbd2/sections/.parainstructions’: Read-only file system chmod: changing permissions of ‘/sys/module/jbd2/sections/.text.unlikely’: Read-only file system chmod: changing permissions of ‘/sys/module/jbd2/sections/__ksymtab_strings’: Read-only file system chmod: changing permissions of ‘/sys/module/jbd2/sections/.rodata.str1.8’: Read-only file system chmod: changing permissions of ‘/sys/module/jbd2/sections/.ref.data’: Read-only file system
rm -rf /*と同様にエラーを吐きながらも終了しました。
続いて各種コマンドを実行したところ、いずれもPermission deniedと表示されて、何もできない状態になりました。ただ例外として、exitのみ正常です。私が望んでいたのはこれです。これ。
$ ls -l / -bash: /bin/ls: Permission denied $ dir -bash: /bin/dir: Permission denied $ whoami -bash: /bin/whoami: Permission denied $ exit logout
セッションを一度閉じて再度接続した場合もrm -rf /*と異なるメッセージが表示されました。テンション上がってきました。
Preparing your terminal... Failed to open session : Timed out while opening the session Trying to open session (Retrying. Attempt #1) Connection is lost. Please refresh the browser to re-establish the connection. Failed to open session : Timed out while opening the session Trying to open session (Retrying. Attempt #2) Connection is lost. Please refresh the browser to re-establish the connection. Failed to open session : Timed out while opening the session Trying to open session (Retrying. Attempt #3) Connection is lost. Please refresh the browser to re-establish the connection. Failed to open session : Timed out while opening the session Trying to open session (Retrying. Attempt #4) Connection is lost. Please refresh the browser to re-establish the connection. Failed to open session : Timed out while opening the session Trying to open session (Retrying. Attempt #5) Connection is lost. Please refresh the browser to re-establish the connection.
最後に伝家の宝刀CloudShell再起動を試してみます。コマンドは正常に実行できたのですが、再接続すると通常はホームディレクトリ(/home/cloudshell-user/)がカレントディレクトリのところ、/rootがカレントディレクトリとなっていました。/homeの権限を確認してみると、全ての権限がない状態になっていました。
$ pwd / $ ls -ld /home d--------- 3 root root 4096 Dec 18 07:57 /home
元々の権限は755だったので、対応としてchmod 755 -R /homeで権限を戻してあげます。
# rootユーザーへの昇格 $ sudo -i $ chmod 755 -R /home $ ls -ld /home/ drwxr-xr-x 3 root root 4096 Dec 18 07:57 /home/ $ ls -l /home/ total 4 drwxr-xr-x 3 cloudshell-user cloudshell-user 4096 Dec 18 08:14 cloudshell-user $ ls -l /home/cloudshell-user/ total 0
意図した権限に変わったことを確認した後、CloudShellを再起動してカレントディレクトリを確認しところ、正常にホームディレクトリ(/home/cloudshell-user/)がカレントディレクトリとなっていました。
$ pwd /home/cloudshell-user
再起動で復元はするけどホームディレクトリは元に戻らないので要注意
AWS CloudShellで「rm -rf /*」を実行してみました。
再起動で実行環境は確かに復元はしますが、当然ながらホームディレクトリ($HOME)は元に戻らないので要注意です。「自分も試しみたい!!」という方がいれば必ず何も保存していない、業務に影響のない環境で試してください。(それでも事故の元なので推奨はしません。)
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
